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ABSTRACT 


UoSAT/OSCAR-11 contains a digital store- 
and-forward communications facility. This 
paper presents some background on the 
development and implementation of this 
experiment as well as describing its de- 
sign. 

BACKGROUND: PACSAT 
The Radio Amateur Satellite Corporation 
(AMSAT), in conjunction with Volunteers in 
Technical Assistance (VITA), is currently 
developing a Packet radio "flying mail- 
pox", dubbed PACSAT (for PACket SATel- 
lite). This satellite is projected to 
contain two identical digital store-and- 
forward communications facilities, each 
containing 2-megabytes of storage capacity 
with multiple uplink channels in the 435- 
438 MHz satellite sub-band and downlinks 
in the 2-meter satellite sub-band. 


During a design review conference held in 
Boston during the weekend of 28 July 1983, 
representatives from the University of 
Surrey (creators of UoSAT/OSCAR-9) indi- 
cated a potential launch opportunity for 
an Amateur satellite with the LANDSAT D' 
mission, scheduled for February, 1984. 
While this launch was far too soon for 
PACSAT, which will incorporate many new 
design concepts, it was viewed as a candi- 
date for flying a communications experi- 
ment based on some of the new technology 
expected to be applied in PACSAT. 


The opportunity not being officially con- 
firmed by NASA, and the development sche- 
dule being brief to the point of absurdi- 
ty, no public announcement was made of the 
possibility of an early 1984 Amateur digi- 
tal communications satellite after the 
meeting. 


UoSAT/OSCAR-11: THE OPPORTUNITIES 


The team at the University of Surrey, 
under the direction of Dr. Martin Sweet- 
ing, saw the potential launch of UoSAT-B 
as a chance to further their experiments 
on gravity gradient stabilization, thwar- 
ted by a recalcitrant boom on UoSAT/OSCAR- 
9, as well as provide another opportunity 
to explore the near-earth region of space 
with various radiation detectors, particle 
detectors and the like. It would also 
afford an opportunity to gain further 
experience with satellite construction. 
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The PACSAT digital design groups viewed 
the launch opportunity as a chance to 
prove certain concepts envisaged for PAC= 
SAT, as well as a chance for "calibration" 
in satellite design. The satellite would 
provide a proving ground for protocol 
development and experimentation for the 
PACSAT mission. In addition, it would give 
some members of the design team a chance 
for early hands-on satellite experience 
prior to the actual launch of PACSAT in 
1986. Finally, some members of the team 
saw UoSAT=-B as an opportunity to try new 
battery management techniques in an effort 


to lengthen the service life of "Phase 
Two" (low orbit, long-life) Amateur satel- 
lites. 


VITA viewed the opportunity as a way to 
establish "proof of concept" by actual 
field trials during the more ambitious 
PACSAT design phase. 


DIFFERENCES IN OSCAR-11 AND PACSAT 


PACSAT will use advanced modulation and 
access techniques to maximize reliability 
and minimize bandwidth requirements. It 
will have four uplink channels per Packet 
experiment and one downlink; there will be 
two complete experiments on board. Each 
channel is expected to support a data rate 
of 9600 bits-per-second (bps). Each exper- 
iment will contain 2-megabytes of data 
storage memory. There will be multiple 
microprocessors in each experiment. HDLC 
will be used; an extended AX.25 style 
protocol will be implemented and the 
satellite will be generally available to 
all Amateurs. 


OSCAR-11, on the other hand, contains only 
a single digital communications experiment 
(DCE). It has 126-k of total RAM capacity, 
16-k of which is error-detecting-and- 
correcting (EDAC) memory for program stor- 
age, system stack and the like. The lim- 
ited uplink and downlink resources mean 
that the DCE must time-share with other 
spacecraft use of the beacons. OSCAR-11 is 
a general research satellite: the DCE is a 
secondary experiment, not the primary one. 
Modulation is simple AFSK of an F3 signal: 
the data rate is limited to 12@@ baud. The 
data encoding technique uses simple UART- 
compatible asynchronous characters instead 
of the more complex (and more efficient) 
HDLC formats in common Amateur Packet use. 


the DCE 


Further, is a proof-of-concept 
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experiment to prove (or disprove) the 
viability of certain recent technological 
advances for use in low earth orbit in a 
limited radiation environment. Hence, much 
of the task of the system is to exercise 
and report on the state of the memory 
devices, current consumption, changes in 
operational behavior and the like. 


Nonetheless, OSCAR-11, through the DCE 
facility, provides a unique opportunity 
for developing non-real-time gateway oper- 
ations for Packet radio use. Such gateway 
activity, while limited to only a relative 
few stations with direct access to the 
satellite, will provide the opportunity 
for a relatively large number of users to 
participate in the usage of OSCAR-11 by 
sending traffic through the gateway sta- 
tions. 


The remainder of this paper will focus on 
the design and implementation of the Data 
Communications Experiment, or DCE, cur- 
rently flying on UoSAT/OSCAR-11. 


DCE: DESIGN OVERVIEW 


The PACSAT project design team is spread 
across the North American continent. The 
PACSAT groups involved in the DCE are: 


APU/CCU (Applications Processor Unit/Chan- 
nel Communications Unit) = based in Tuc- 
son, Arizona. This team is responsible for 
the computing hardware design for the 


various PACSAT microprocessors. 


Ground Station = based in Dallas, Texas. 
This group is responsible for the PACSAT 
ground station design (not to be confused 
with the satellite command stations). 


RAMUNIT (Mass Storage) = based in Ottawa, 
Ontario. This group is responsible for the 
2-megabyte mass storage subsystem design 
to be used in PACSAT. 


SOFTWARE = based in Los Angeles, Califor-— 
nia. This group is responsible for all 
software that will run in the processors 
designed by the APU/CCU group. 


Unlike previous AMSAT satellites, PACSAT 
will depend on the use of high-speed mi- 
croprocessors. The most sophisticated Ama- 
teur satellite to date, AMSAT/OSCAR-1@, 


The microprocessor chosen for PACSAT is 
the National Semiconductor NSC-800. This 
is a z-80 work alike device, able to draw 
on the vast resources of proven Z-80 soft- 
ware design tools. Capable of executing 
instructions at a rapid rate when operated 
with a 4 MHz clock, studies by the soft- 
ware design group determined that this 
processor would be capable of performing 
the necessary tasks associated with data 
collection and management projected for 
the PACSAT mission, 


However, AMSAT has no flight experience 
with the NSC-896, nor with any low-thres-— 
hold CMOS devices. Thus, the NSC-8@g was 
selected to fly on the DCE in order to 
evaluate th high-speed, low-threshold 


CMOS technology of which it is fabricated 
in the low-earth orbit environment. 


The DCE's NSC-800 is buffered, and its 
address/data bus demultiplexed, via 5-volt 
high-speed CMOS (HCMOS ) devices of the 
S4HCXXX family. 


This, too, represents a departure from the 
relatively "safe" high-threshold silicon- 
gate technology traditionally flown in 
space applications. The nature of radia- 
tion damage to MOS semiconductors is such 
that the switching threshold voltage tends 
to rise- This is due to trapped charges in 
the gate oxides that occur when bombarded 
by particles with the right energy levels. 
A high-threshold device, operating at 14- 
volts, has more "headroom" in which to 
sustain damage before its input switching 
thresholds approach the Vdd level (10- 
volts). In the case of PACSAT, and the 
DCE, higher-speed operation is of para- 
mount importance -- standard CMOS devices 
simply won't do the job needed. Thus, a 
higher-risk technology is employed to 
allow the task to be accomplished at all. 
he DCE provides a mechanism to evaluate 
this risk in a real space environment. 


[The primary DCE memory is comnased of CMOS 
static RAM. There is a 16-k byte block of 
memory that includes a Hamming code EDAC 
section. This memory is built around Har- 
ris 6564 ICs, a hybrid utilizing 4k by 1 
CMOS static RAMs. The E'DAC support logic 
is fabricated entirely of HCMOS devices. 
An error counter is mapped into the NSC- 
800 I/0 space to allow the processor to 


uses the RCA 1892-series COSMAC micropro 
cessor. This device, while available in a 
radiation tolerant form, is not fast. How- 
ever, it will run on 198-volts and is more 
than adequate for the task of managing the 
spacecraft's resources. PACSAT must rely 
on processing power to perform its mission 
as well as manage the various spacecraft 
support systems: the 1802 simply isn't 
powerful enough. In fact, no single micro- 
processor available in CMOS is powerful 
enough -- PACSAT will use three micropro- 
cessors per Packet experiment, or six 
total. The spacecraft itself may require 
the use of yet another! 


determin th number of errors corrected, 


The Integrated Housekeeping Unit {IHU) -- 
the microcomputer that manages the opera- 
tion of OSCAR-11 -- is designed around the 
1802 and has an EDAC memory built around 
4116 DRAMs and traditional 4000 series 
CMOS logic. This unit also has an error 
counter, and one of the most important 
areas of measurement associated with the 
technology evaluation is the comparison of 
the two error counters. This information, 
coupled with the absolute levels of radia-— 
tion as measured by other detectors on 
board the spacecraft, will help determine 
the suitability of CMOS static RAMs for 
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future satellite packages, including PAC= 


SAT. 


The limited knowledge available (at least, 
in non-classified form), indicates that 
DRAM is best for overall power consumption 
over the projected life of the satellite 
-mission, while CMOS is better initially. 
UoSAT/OSCAR-11 will give us valuable data 
as to the relative performance of these 
technologies in the particular environment 
of low earth orbits. If the degradation in 
performance (as measured by changes in 
nominal current consumptions when the cpu 
is performing well-known tasks) is accep- 
table, CMOS static RAM may offer the op- 
portunity to reduce power consumption, a 
major consideration in spacecraft systems 
design. The radiation experiments, along 
with relative errors-corrected data, may 
show which technology is more tolerant of 
the particular low earth orbit environment 
which OSCAR-11 (and later, PACSAT) inha- 
bits. 


Additional RAM is provided in the form of 
2k-by-8 "bytewide" CMOS static RAMs. A 
total of 14k-bytes of Harris military 
grade 6516 components are used. While 
there is no hardware EDAC circuitry used, 
this memory will be used to determine the 
susceptibility of this technology to radi- 
ation induced errors -- again, the EDAC 
memory counter will provide invaluable 
data for comparison purposes. 


EDAC circuitry is not really useful for 
bytewide components a grazing particle 
may upset the data in several cells, and 
this could mean that many bits of a par- 
ticular byte are corrupted, making a very- 


wide word memory necessary to detect, much 
less correct, such errors. Instead, it is 
envisaged that a software encoding scheme 


could be implemented to correct these 
errors, Similar to the "fire codes" used 
to recover from error bursts when reading 
from a Winchester disk, for example. Error 
detection will be fairly simple in some 
experiments when a predictable pattern is 
written to memory and later read back for 
comparison. 


The PACSAT mass storage mechanism current- 
ly being explored is that of arranging a 


large amount of high-speed static CMOS RAM 
in a bank-switched scheme in the upper 
address space of the NSC-808. High density 
(8k-bytes per chip), low-threshold CMOS 
devices were selected for a portion of 
this memory in the DCE (Hitachi HN6264LP- 
12s), with lower density RAMs serving to 
implement other banks (Hitachi military- 
style 6116s). Bank selection and bus iso- 
lation is via 5-volt HCMOS logic of the 
54HCXXX family. 


Bootstrapping the processor from a cold 
start uses a scheme with bank selected 
CMOS fusible link PROMs. EPROMs are unuse- 
able due to their dependence on trapped 
charges for memory retention. The PROM 
technology selected has been used in space 
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before, although little data is officially 
available on their performance. 


To help ensure reliability, a pair of 


PROMs, bank selectable by the spacecraft 
command decoder, are incorporated in the 
DCE. 


The use of PROM in space is another first 
for the DCE for AMSAT applications, at 
least as far as bootstrap memory is con- 
cerned. The 1802 has a special mode of 
operation that allows boostrapping code 
directly into RAM without any ROM whatso- 
everl The NSC-800, on the other hand, does 
not easily lend itself to such usage (al- 
though the Japanese JAS-1 Amateur satel- 
lite, scheduled for an early 1986 launch, 
uses a ROMless NSC-800). This meant that a 
thoroughly tested, absolutely bugqfree 
bootstrap loader had to be designed, tes 
ted and burned into the PROM prior to 
construction of the flight DCE! While 
developing such a program may appear sim- 
ple at first glance, the task is not tri- 
vial. The system must be errorless in its 
loading, function without any RAM whatso- 
ever for the loader (no absolute memory 
location can be considered safe from fail- 
ure in space applications) and must work 
well in a very noisy (error-prone) envi- 
ronment. This task was accomplished by the 
RAMUNIT group, with assistance from the 
Software team. 


Serial I/O is handled by a pair of 6402 
UARTs. These devices were successfully 
flown in UoSAT/OSCAR=-9 and they are compa- 
tible with the NSC-800. There are two 
UARTs and they are multiplexed to enable 
communication with any receiver, transmit-— 
ter or serial data stream in the space- 
craft (the IHU, for example). Serial I/0 
may be operated in an interrupt-driven or 
a polling fashion. 


Parallel I/O is handled by a Harris 
82C55A. It is allowed to control the ser- 
ial port multiplexers, read data from the 
navigation magnetometer, select the UART 
data rate clocks, determine the cpu clock 
rate and select the RAMUNIT active bank. 


A tap in the clock oscillator/divider is 
coupled to an interrupt line to allow the 
NSC-800 to keep track of elapsed time for 
various internal experiments. 


Finally, level-shifters are provided to 
interface the DCE with the rest of the 
spacecraft. Command control is asserted 
over the DCE reset line, bootstrap PROM 
select, cpu clock rate (0.9 or 1.8 MHz) 
and DCE power on/off. Telemetry status 
points indicate the state of all the com- 
mand lines to the DCE, while telemetry 
channels provide measurement of current to 
the RAMUNIT, the CPU and the EDAC memory 
subsystems. 


DCE: 


DESIGN HISTORY 


With the limited time available to imple- 
ment the DCE, many decisions had to be 


made rapidly and implemented in no less 
timely a fashionl 


Investigations were made into memory tech- 
nologies, component availability and EDAC 
memory design by the APU/CCU group during 
the month of August. Meetings were held 
with various AMSAT engineering people and 
vital information obtained. 


The wire-wrap prototype of the NSC-800 
based cpu and memory systems was accomp- 
lished during the Tucson floods of Septem- 
ber, 1983. 


By October, the Ground Station group was 
busily preparing to lay out the PC boards 
for the CPU and GMEM (General MEMory) 
cards. The wire wrap prototypes were made 
functional in Dallas and the layout work 
began in earnest. 


By the first part of December the artwork 
was delivered to Tucson and the actual 
flight PC boards fabricated. These were 
hand carried to Dallas where the engineer- 
ing prototypes were constructed. The re- 
maining boards and parts were then sent by 
air to Ottawa where the actual construc- 
tion of the flight units was to take 
place. 
M 


eanwhile, the NiCd cells were procured 
and sent to Ottawa in October for evalua- 
tion, classification, and integration into 
the spacecraft's battery. The cells were 
then shipped on to Surrey. The RAMUNIT 
design was completed and the PC boards 
laid out and fabricated in Canada. 


The group leader in Ottawa was severely 
burned in a fire about this time: although 
his recovery was very painful, he doggedly 
persisted on the project. 


Software for the DCE was developed in 
Ottawa and Los Angeles, with the final 
burning into PROM carefully controlled by 
the Ottawa group. 


In early January, the flight boards were 
constructed and integrated into the flight 
module (three circuit boards crammed into 
a container only 31 mm thick!) in Ottawa, 
with full-time participation by the PACSAT 
project leader. 


The flight unit was hand carried from 
Canada to Surrey, where it was further 
tested and integrated into the spacecraft. 
The final hardware bugs were exterminated 
with coordinated efforts from both sides 
of the Atlantic. 


The flight DCE arrived in the States in 
mid-February as part of UoSAT-B. Magneto- 
meter calibration was accomplished at 
Goddard Space Flight Center, and the sa- 
tellite and support team then travelled to 
Vandenberg Air Force Base, on the Califor- 
nia coast. There, it was met by members of 
the DCE team, and several days were spent 
verifying the overall health of the DCE 
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and the spacecraft in general. All passed 
with "flying" colors... 


OSCAR-11: A STATUS REPORT 


UoSAT-B became UoSAT-2/OSCAR-11 on 1 March 
1984 after a textbook launch on a Delta 
vehicle. Initial telemetry was positive. 


On March 2nd, however, an anomaly occurred 
with the 145.825 MHz beacon transmitter. 
As of this writing (19 March 1984), the 
spacecraft is silent, its command receiver 
at 78-cm apparently being blocked by the 
iling 2-meter beacon. Teams at Surrey and 
os Angeles are actively trying to unravel 
he puzzle and get the satellite ina 
unctioning mode. With persistence and a 
ittle luck, 1984 should herald the acti- 
ation and use of the first major digital 
tore-and-forward Amateur communication 
acility in space: this should put empha- 
is on the development of a workable gate- 
way plan. 
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DCE : THE PLAYERS 


The author wishes to recognize the many 
volunteers who made the DCE possible. Any 
omission is purely unintentional. 

DCE Project Leader : Harold Price, NK6K 
Ottawa Team List (Battery and DCE) 


UoS-B Battery Development Team 


R. D. (Dick) Atkinson = VE3JBO 
R. B. (Bob) Gillies - VE3JA 
S. J. (Stan) Kazmiruk =- VE3JBA 
G. S. (Gord) Scale - Non Amateur 


DCE Software 


H. J. (Hugh) Pett - VE3FLL 


DCE RAMUNIT and Construction 


R. H. (Ron) Archer - VE3CNM 

G. H. (Grant) Bechtold = VE3JBF 

G. 0. (Geoff) Clarke - VE3JBD 

M. S. (Murray) Gold - VE3KHG 

J. M. (John) Henry - VE2VQ 

L. s. (Larry) Kayser ~ WA3ZIA 

S. J. (Stan) Kazmiruk - VE3JBA 

W. G. (George) Roach - VE3BNO 

G. S. (Gord) Scale - Non Amateur 
D. E. (Dale) Ward - Non Amateur 
U.S. Team 


DCE CPU and General Memory Design, Layout, 
Prototype construction and software. 


Dave Cheek - WA5SMWD 
Chuck Green = N@OADI 
Lyle Johnson = WA7GXD 
Harold Price = NK6K 

Bill Reed - WDG9ETZ 
Jose Sancho - WB5SYFU 
Bob Stricklin = N5BRG 
and of course, AMSAT, VITA and the 
University of Surrey... 


